(1) Field of the Invention
This invention relates to a test support program and method for checking program performance, and more particularly, to a test support program and method for checking program performance with a stub.
(2) Description of the Related Art
When we develop software, we always verify its operation before actual use. Preferably, we occasionally verify the operation in the middle of programming to increase efficiency of the development. To check the operation, stubs which serve as incomplete functions are prepared. A stub is a mediation program so that a program can call up another program. In operation check, the stub returns a prescribed response to a call made based on a program being checked, according to the predefined program design, instead of incomplete functions. Therefore, even if some functions are incomplete, the operation of the other functions can be checked.
With such stubs we can easily conduct automatic operation check. For example, a stub group composed of plural stubs is prepared. When a module is called up while software being tested is running, a stub corresponding to the module is selected from the prepared stub group under predefined conditions and executed (for example, refer to Japanese Unexamined Patent Publication No. 2000-132425).
Recently, electronic commerce (e-commerce) over the Internet is very common. Companies order products or send quote over the Internet with their web servers by e-commerce.
In developing e-commerce systems, reliable operation test cannot be conducted because data cannot be sent to business partners' systems. That is, in e-commerce between companies, each partner's system and the own system communicate with each other via a network. Therefore, to establish an e-commerce system, not only the own system but also connection with partners' systems should be tested. However, the business partners will get troubled if they receive a large amount of test data every time when a regression test is performed for modification of the own system. This regression test is conducted when a program is modified, in order to see if unintended results occur due to the modification.
In addition, even if message can be sent to partners' servers for the operation check, desired responses would not be returned. Therefore, the test cannot be done for various situations that probably occur, which results in an inefficient and unreliable test. For example, to check system performance for a situation where a partner's server is under maintenance, the partner's server should be actually under maintenance. In other words, the operation check cannot be performed until the partner's server enters into maintenance.
As an alternative method, a regression test with a stub can be considered, the stub simulating the functions of a partner's server. However, since the performance of the partner's server is designed by the business partner, responses cannot be specified at the time of development of the own e-commerce program. The conventional stubs employ any of the following methods.    Automatically create and return a response form by applying some rules (continuous number or random number).    Keep transactions sent from business partners as they are, and use them as response forms in test.    Automatically create and return data of a response form based on the data of an input form.
However, all the above methods are unpractical in view of objectives of creating and returning a response which is appropriate to a request form and is effective in test. That is, since the stub makes responses (including intentional error responses) according to a predefined program design, various kinds of responses which are probably sent from business partners in e-commerce should be analyzed and defined. This analysis and definition, however, require thousands of man-hours. This is impracticable.